Wp-calypso: Reader: The core Buttons block renders as a line of text in the list view.

[kwight]

The list view of the Reader will display content with Buttons blocks as a line of unstyled text.

Detailed View | List View
--- | ---
|

[krymson24]

Taking a step back to address this in a more scalable and consistent way -- brainstorming being done here: paYKcK-K9-p2

[krymson24]

@kwight so there's two issues here for those two different views --

1. The Detailed View contains the buttons with classes without the styles from the original post.
2. The List View contains the buttons as just text.

Based on our conversation, I believe you said that the Detailed View should be the priority. In that case, should this ticket read to fix the styling on the Detailed View, or should I create a new ticket for it?

If we're addressing the list view, the P2 I posted is still relevant, and I can decide on a solution for that. However, with the Detailed View being the priority, I'll detail here what needs to be done for that. The Detailed View is actually rendering the full HTML of the post. What's missing are the styles for the specific classes applied. From my understanding, we can apply @mmtr's work here. I took that approach here D51542-code, but it doesn't seem to be doing what I expect, that is, taking the styles associated with the classes, and injecting them into the HTML as inline styles. Furthermore, it removed the whole Table block in one of my posts

@mmtr given the diff, am I not consuming the API correctly? Is that not what I should expect it to do? This is the same problem we were experiencing here: https://github.com/Automattic/wp-calypso/pull/46476#pullrequestreview-511638869. I just want to confirm with you that my understanding is correct. I'll look into seeing why styles for classes aren't being injected into HTML, and also why my Table block is getting stripped from my content. 🤔

[mmtr]

Sorry @krymson24, I'm not following you here.

The inlining styles process implemented in D50508-code hooks into the the_content filter, so we shouldn't call A8C\Gutenberg\inline_blocks_styles directly.

The post_content and post_content_full properties you're modifying in D51542-code should have been already filtered by the_content, which is why we can see inline styles in the API response of the /read/following endpoint when testing D50508-code.

Is the issue specific to the button classes/styles (meaning that styles of other classes are inlined)? If so, then likely our process is hitting some edge case for the wp-block-button__link classes that we should identify.

A good first step would be to debug the \A8C\Gutenberg\inline_blocks_styles function and see if it is failing to convert any class to inline styles. If that looks ok, then check the response of the API used by the reader and see if it includes the inline styles. If that looks ok too, then I guess the JS client of the reader is not rendering the styles/classes told by the API response.

[mmtr]

A good first step would be to debug the A8C\Gutenberg\inline_blocks_styles function and see if it is failing to convert any class to inline styles. If that looks ok, then check the response of the API used by the reader and see if it includes the inline styles. If that looks ok too, then I guess the JS client of the reader is not rendering the styles/classes told by the API response.

I just did this and it seems the issue is on the JS client.

When D50508-code is applied, the API returns a response that includes the inline styles, however they are not applied to what's rendered:

The post content is rendered using the FullPostView component, but the post.content we inject to render the HTML doesn't contain the styles:

https://github.com/Automattic/wp-calypso/blob/d357d1d2f8180e1ba53b7847ef09debbefcacbab/client/blocks/reader-full-post/index.jsx#L476

We need to figure out why that post object doesn't contain the styles returned by the API. Maybe it is set from the response of a different API response or maybe they're stripped out as part of a sanitization process somewhere.

[krymson24]

Cross-update from D51587-code

It looks like the fallback is triggering at some point, it seems that it gets triggered, but doesn't get applied to the content that is returned in the response. I haven't been able to narrow it down to exactly where, but I'll continue my investigation tomorrow, so it'll solve the inline styles problem for the Reader as well. I also tried adding an apply_filters('the_content', $post_content) hook right before the post content gets set, but the inline styles aren't applied to the post.

                case 'content' :
                    apply_filters( 'the_content', $feed_item->post_content);
                    l('$feed_item', $feed_item->post_content);

[krymson24]

I think I've reached a blocker for my reader work. I understand that when the filter is added, there's a priority level for when filters gets executed. So I tried adding this add_filter( 'the_content', __NAMESPACE__ . '\inline_block_styles', 999999999999 ); and I would expect that this filter gets applied last, regardless of what was applied previously. However, that doesn't seem the case because I don't see the inline block styles added to the content. I don't think I have a good debugging process with these filters and I'm trying to find ways to answer the following questions:

1. What's the best way to find the order of execution applied for WordPress filters?
2. What's the best process to debug added filters (can imagine even if I get the order of execution, there could be a lot to go through) and applied filters (I was trying to find where this filter was being applied and I think trying to trace down the apply_filters() call can be a real time sink and rabbithole)
3. Does anyone have any intuition as to what the problem is or what I should look further into?

[krymson24]

This should be solved by D51569-code and https://github.com/Automattic/wp-calypso/pull/46720

[krymson24]

Outstanding questions here: D51569-code before this can be resolved

[kwight]

Reader changes for the sake of better block rendering needs further investigation; see paYKcK-KO-p2 for context.