[Block] Comment Template color adjustment -> Overrides inner child color adjustments

[paaljoachim]

I have edited this issue. 26 July 2022

Description

Examples
Comments > Comment Template > Columns > Column > Row > Comment Date and Comment Author. Change the link color of each.

Comment Template. Change the Link color and notice that it also affects the inner blocks where the color has already been adjusted.

Step-by-step reproduction instructions

1. Add the Comments Query Loop block.
2. In Comments > Comment Template > Columns > Column > Row > Comment Date change the link color.
3. In Comments > Comment Template > Columns > Column > Comment Author Name change the link color.
4. Go to Comments. Change the link color and notice it changes all the links also the Comment Date and Comment Author Name even though these are defined in their own blocks.

Screenshots, screen recording, code snippet

Changing the Comment Date link color.

Changing the parent Comment link color also affects inner child blocks.

Environment info

WP 6.0.1
Gutenberg plugin 13.7.2
Twenty Twenty Two
Chrome

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[carolinan]

The edit link and comment reply link are always links and their color is changed by the link color option, not the text color option.

I do see a related issue:

Editor
When I change the link color of the comments query loop, the color of the edit link and the reply link inherit this color, even if they already specify their own link color in their own block setting.

Front
The edit and reply link uses the correct, individually assigned colors.

[paaljoachim]

I have gone ahead and edited the issue title and the issue content to reflect that changing color of the parent block Comments will also change inner blocks that have already defined inner colors.

[paaljoachim]

Hey @michalczaplinski
This might be an issue for you to take a closer look at.

[michalczaplinski]

After taking a quick look I can indeed confirm the issue @paaljoachim

If you'd like to send a PR with a fix that would be awesome. I would be very happy to help 🙂

As mentioned by @carolinan, the issue is only present in the editor:

2022-07-26_18-11-46.mp4

[paaljoachim]

Thanks for going through @michalczaplinski

I am wondering if the fix would be a general fix for all parent blocks that affects the inner blocks that have already been modified and should not be overwritten by changes the parent block makes.

Hopefully a developer will show up that can fix the issue.
I will also ping Carlos @c4rl0sbr4v0

[michalczaplinski]

I dig a little more here and the same issue appears in the Query Loop block. There are 2 twists though:

1. The correct styles are applied after reloading the editor page:

2022-07-28_17-11-11.mp4

2. The editor is sensitive to the temporal order in which the styles are applied.

• If we first change the styles of the child (e.g. Comment Date block) and then the styles of the parent (e.g. Comment block) the parent styles win, which is incorrect.
• If we first change the styles of the parent and then the styles of the child, the styles are applied correctly.

2022-07-28_17-13-31.mp4

[michalczaplinski]

Hi @oandregal 👋 I have a question

In this comment you mention that:

Applying the link color is not deterministic in the editor. If I apply the link color to the paragraph and then to the group, the link color is the one set by the group. If I do it the other way around, the link color is the one set by the paragraph.

This is precisely the problem that we see in the current issue. Do you know if this behaviour is intentional or can be considered a bug?

[paaljoachim]

Heya Nik @ntsekouras I believe this is an issue you might want to know about as well.

[ntsekouras]

👋 - It's not specific to Query Loop or Comments Loop. It's related to color support in general. You can reproduce with just a Group block. Actually the main issue is the one @michalczaplinski linked: #37582 and probably other supports have this..

I think this can be closed as duplicate. What do you think?

[paaljoachim]

Yeah. It looks like this is a duplicate issue and can be closed. I will let Michael decide.

[michalczaplinski]

Indeed, let's close this one in favour of #37582 🙂