Tag Cloud: Add typography supports (except font size)

[amustaque97]

Related:

• Tracking: Addressing Design Tooling Consistency #43241
• Tracking: Typography Design Tools Consistency #43242

What?

• Add typography support to Tag-cloud block (except font size)

Why?

• Allows typographic styling of Tag Cloud links

How?

• Opts into typography support expect font size.

Testing Instructions

1. Load the editor, add a tag-cloud block and select it.
2. Test various typography settings ensuring styles are applied in the editor.
3. Save and confirm the application on the front end.
4. Test theme.json styling of the block.

Example theme.json snippet

                        "core/tag-cloud": {
				"typography": {
					"letterSpacing": "5px",
					"fontStyle": "italic",
					"fontWeight": 300
				}
			},

NOTE: Font size is already present and was merged as a part of #37311

Screenshots or screencast

[carolinan]

While testing this with Twenty Twenty-Two and Twenty Twenty-Three, I am getting a JS error when I try to change the font family setting.

400:
index.js:101          GET http://localhost:10003/wp-json/wp/v2/block-renderer/core/tag-cloud?context=edit&attributes%5BnumberOfTags%5D=45&attributes%5Btaxonomy%5D=post_tag&attributes%5BshowTagCounts%5D=false&attributes%5BsmallestFontSize%5D=8pt&attributes%5BlargestFontSize%5D=22pt&attributes%5BfontFamily%5D=system-font&_locale=user 400 (Bad Request)

"Objects are not valid as a React child"
react-dom.min.js?ver=6.0.1:1 Error: Minified React error #31; visit https://reactjs.org/docs/error-decoder.html?invariant=31&args[]=object%20with%20keys%20%7Berror%2C%20errorMsg%7D for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
    at l (react.min.js?ver=6.0.1:1:2112)
    at c (react.min.js?ver=6.0.1:1:2267)
    at Object.toArray (react.min.js?ver=6.0.1:1:9096)
    at C (raw-html.js:25:2)
    at ft (react-dom.min.js?ver=6.0.1:1:43451)
    at Wt (react-dom.min.js?ver=6.0.1:1:50270)
    at ts (react-dom.min.js?ver=6.0.1:1:112276)
    at Fr (react-dom.min.js?ver=6.0.1:1:77758)
    at Dr (react-dom.min.js?ver=6.0.1:1:77686)
    at Rr (react-dom.min.js?ver=6.0.1:1:77549)

[paaljoachim]

Perhaps @talldan Dan and @gziolo Greg could also take a look....

[aaronrobertshaw]

I can replicate the issue @carolinan reported. The same error is encountered if you try to add font family support to the Archives block.

Tag Cloud	Archives

[amustaque97]

400:
index.js:101          GET http://localhost:10003/wp-json/wp/v2/block-renderer/core/tag-cloud?context=edit&attributes%5BnumberOfTags%5D=45&attributes%5Btaxonomy%5D=post_tag&attributes%5BshowTagCounts%5D=false&attributes%5BsmallestFontSize%5D=8pt&attributes%5BlargestFontSize%5D=22pt&attributes%5BfontFamily%5D=system-font&_locale=user 400 (Bad Request)

@Mamaduka, can you please share your input on how can I fix this issue? I saw a similar issue was fixed by you in the PR #40468

Just for the trial, I tried to add a condition similar to lock for font family and it give me a different error saying fontFamily type is not object. If there are any references or resources please feel free to share.

Thank you.

[aaronrobertshaw]

@amustaque97 thanks for highlighting #40468, it lead me to what I think is the cause of the problem when switching font family. I have a PR up to fix this in #43937.

[aaronrobertshaw]

@amustaque97 #43937 has been merged so if you can rebase this PR, we should be in a good position for a final review 👍

[amustaque97]

Indeed that fix works 👏🏻 . Here is a small recording of the font family activity for the tag-cloud block.

Screen.Recording.2022-09-07.at.8.15.30.PM.mov

[aaronrobertshaw]

Thanks for working on this one @amustaque97 👍

I've taken it for a spin, and for most of the supports adopted, it works well. Unfortunately, the text-decoration styles are not applied cleanly at the individual block level or via theme.json/global styles.

We might need to tweak our approach to adopting typography supports for this block. An alternative approach might be:

• Skip serialization of the typography supports
• Update the server-side rendering of the block to generate the classnames and styles and apply these to the inner links
• Use __experimentalSelector to define a feature level selector for these typography supports so theme.json/global styles can generate applicable styles
• Tweak the block styles such that theme.json and global styles apply the text-decoration

The current state of the work adding typography supports to the Search block might provide some clues although the approaches will differ somewhat.

users should not be encouraged to setting font-family locally, which is why it should not be visible by default (ellipsis menu) on block instances

The font family control shouldn't be exposed by default so we'll need to tweak that in the block.json. See #39642 (comment) for a full explanation.

---

The following suggestions are nitpicky, but they will help others understand the scope of this PR better when they come across it for historical context.

• Change title to "Tag Cloud: Add typography supports (except font size)"
• Update the What? section: "Add typography support to Tag-cloud block (except font size)"
• Replace the copy/paste error in the Why? section: "Allows typographic styling of Tag Cloud links"
• Correct the How? section as this PR doesn't adopt all typography supports and shouldn't show font-family by default
• Add test instructions for theme.json and global styles so more reviewers can help out

---

Unrelated to the work in this PR, there are a couple of follow-ups we should look at as well:

• When either smallest/largest font size fields are cleared the block crashes
• These font size fields should be relocated to the Typography panel (via SlotFill).

---

Thanks again for tackling this block @amustaque97, I appreciate the edge cases around some of these block supports can provide a few headaches.

[aaronrobertshaw]

Thanks @amustaque97 for updating the PR title and description.

Sorry for the slow re-review on this, I was waiting for the updates to remove the font family as a default control and switching to the new approach to solve the issues noted in my last review.

I'd be happy to pick up this PR and implement my suggestions if that helps. Let me know 🙂

[amustaque97]

@aaronrobertshaw, thank you for checking with me 🙂

Sorry I was quite busy with my office work because of the release. I have removed the font family as default control Let me know if there is any work pending in this PR.

Regarding follow-up,

• When either the smallest/largest font size fields are cleared the block crashes
• These font size fields should be relocated to the Typography panel (via SlotFill).

can we take it up as a part of a different issue?

WDYT?

[aaronrobertshaw]

Thanks for iterating on this one @amustaque97 👍

Let me know if there is any work pending in this PR.

There is still the issue with applying text-decoration styles cleanly, as noted in my earlier review.

I'd be happy to put together an alternate PR that adopts the suggested strategy if that helps.

---

I took a closer look at what might be involved in skipping the serialization of typography supports and applying them directly to the inner links.

Given the tag cloud is generated via wp_tag_cloud() and therefore wp_generate_tag_cloud(), we are a little limited in what we can do. Those functions don't appear to allow passing CSS class names or styles through their $args to be applied to the tag cloud links.

We have a few options given this:

1. Update core to provide the option to pass link classes and styles. Then adopt skipping serialization of typography supports on this block and apply those classes and styles via the block's render callback. While the results of those core functions can be filtered, we'd need to do it only for an individual block which would be a problem.
2. Inject the typography styles and classes into the markup returned by wp_tag_cloud(). This would be fairly brittle, though.
3. Omit text decoration support and rely on the typography supports being applied to the block's wrapper as normal.

As this block already diverges from the standard adoption of all typography supports (see font size), I don't think it would hurt to omit text-decoration support as well. The Tag Cloud block is a dynamic block so there isn't any saved markup in the post content that would force us to write deprecations if we were to change our approach in the future and skip serialization (maybe after those core functions were extended?).

I propose we just remove the text decoration support from the Tag Cloud block and proceed with the block supports that do apply cleanly.

What do you think?

[amustaque97]

I propose we just remove the text decoration support from the Tag Cloud block and proceed with the block supports that do apply cleanly.

As this block already diverges from the standard adoption of all typography supports (see font size), I don't think it would hurt to omit text-decoration support as well.

I agree with you @aaronrobertshaw, sorry for not checking the comment properly. I have removed the text decoration attribute. Overall, the tag-cloud block is a bit tricky to handle and make sure all cases work just fine.

Inject the typography styles and classes into the markup returned by wp_tag_cloud(). This would be fairly brittle, though.

Yes, maybe I'm not sure TBH 😓

[aaronrobertshaw]

Thanks for updating this one again @amustaque97.

LGTM! 🚢

Note: If we do decide to inject styles into the tag cloud's markup later on, we might be able to leverage the WP_HTML_Tag_Processor.